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REMARKS/ARGUMENTS 



Specification Amendment 



The specification is amended as shown above on page 13, based on originally- 
filed Claim 9 on page 30. 

Claim Rejections - 35 U.S.C. 5101 
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Claims 13 and 14 were rejected under 35 U.S.C. §101 as being directed to non- 
statutory subject matter. The Examiner appeared to indicate at the bottom of page 2 of 
the current Office Action that the term 'medium' is broadly interpreted to include waves. 
This statement is traversed because the Examiner has interpreted the word 'medium 1 
out of context. Originally-filed Claims 13 and 14 used the word "medium 15 with an 
adjective "storage" which cannot be ignored. The Examiner has not explained, in the 
current Office Action, as to why the word "storage" is given no patentable weight. 

In paragraph [0042] Applicants have identified three types of media, namely non- 
volatile media, volatile media and transmission media, but note that Applicants have 
only stated that the transmission media can take the form of waves. Accordingly, the 
other two media, namely non-volatile media and volatile media are not to be interpreted 
by the Examiner to cover waves. Hence, Claims 13 and 14 are now amended to 
require "non-volatile media" which includes optical or magnetic disks as stated in line 5 
of Applicants' paragraph [0042]. Non-volatile media also includes various devices such 
as PROM, EPROM, FLASH-EPROM, memory chip, cartridge, magnetic tape, punch 
cards, paper tape etc. as stated in lines 2-5 of paragraph [0043]. Non-volatile media 
does not cover pure waves or signals. In view of the above amendment, Applicants 
respectfully request the Examiner to withdraw the §101 rejection of Claims 13 and 14. 

Claim 1 Rejection 



Claim 1 remains rejected under 35 U.S.C. §102 as being anticipated by US 
Patent 4.785,400 granted to Kojima. This rejection is respectfully traversed as follows. 

In explaining the anticipation rejection of Claim 1, the Examiner stated as follows 
at the bottom of page 3 of the current Office Action: 

i 
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In response to applicant's argument, Kojima teaches in the 
case of a slot for the first row of the table 202 Of FIG. 2B, data "A, 
316" is stored in the slot (see e,g„ col. 7 lines 11-13) and a storage 
location of a row within the subsidiary storage 112 (FIG. 1) can be 
designated by a data page number i and a slot number]. Therefore, 
the combination 301 of the data page number i and the slot number 
j is called a row number (see e.g., col. 7 lines 20-25) wherein the 
data page number referred as row-identifier, the slot number 
referred as value, and a row number referred as a pair. 

In the above-quoted remarks the Examiner admits that Kojima teaches a combination of 
data page number and slot number, together to form a row number to identify a row. 

Hence a first issue with the Examiner's suggestion at the end of the above- 
quoted text, namely "wherein the data page number referred as row-identifier" as stated 
above, is that a combination is necessary for Kojima to identify a row, i.e. Kojima's data 
page number itself (as suggested by the Examiner) is insufficient to fully identify a row. 

Secondly, the Examiner's suggestion "wherein toe data page number referred as 
row-identifier" does not fully identify a row in Kajima's patent for another reason. Kojima 
teaches that his page contains multiple slots. See Kojima at column 7 lines 14-16 
("Each data page 302 includes slot pointers 303 each indicating a starting address of a 
respective one of the slots 304 within the same data page"). Because Kojima's data 
page number identifies multiple rows, it cannot be referred to as a row-identifier. 

Moreover the Examiner's suggestion towards the end of the above-quoted text 
"... the slot number referred as value" is invalid for the following reason. Claim 1 is 
amended to clarify that each value comprises data in the row identified by the row- 
identifier. For support, see Applicants' specification, paragraph [0001], lines 1-5. 
Because Kojima's slot number does not appear to include any data, this is a third issue 
with the Examiner's explanation. 

In explaining the rejection, the Examiner further stated as follows in the top half 
of page 4 of the current Office Action: 
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Applicant argued Kojima does not teach the claimed 
limitation "a 'group' of row identifiers are used 'repeatedly to find 
corresponding page numbers and store the page numbers that are 
thus found in a structure" 

In response to applicant's argument, Kojima teaches an 
analysis part 105 of the program 103 then analyzes the search 
command to determine the most suitable process sequence for that 
search command, generates codes which designate the 
determined process sequence, and stores the process sequence 
designating codes 107 into a control block 106 (see e.g., coL3 lines 
4-9) wherein the process sequence for that search command 
referred as repeatedly finding and the table data to be processed, 
such as the commodity table 201 (FIG. 2A) is stored in units of a 
data page, for example, as shown by 302 in FIG. 5, and these data 
pages are stored in the subsidiary storage 112 with some data 
pages being duplicated in the data buffer areas 1 10 (see e.g. col. 3, 
lines 16-22) which referred as corresponding page numbers found 
and store the page numbers that are thus found in a structure as 
claimed. 

In the above-quoted remarks the Examiner appears to have misunderstood Applicants' 
position. Applicants "claimed limitation" does not require page numbers. In particular, 
please note that there are no "page numbers" in Applicants' Claim 1. 

Also in the above-quoted remarks, the Examiner admits that Kojima's data pages 
are themselves are stored (in storage 1 1 2 or areas 1 1 0) by execution of Kojima's 
codes. 

So, a fourth issue is that Kojima does not appear to teach (in the Examiner-cited 
text) that corresponding page numbers are stored in a structure prior to retrieval of the 
data pages themselves* Claim 1 is amended to clarify that repeatedly finding, and 
storing in a structure are done prior to retrieval of the block. For support, see 
Applicants' specification, paragraphs [0004] and [0005] on page 2. 

A fifth issue is that the Examiner has not shown use of a "database index" by 
Kojima. Note that this limitation was present in originally-filed Claim 1 . However, the 
Examiner appears to have no explicit explanation for this requirement of Claim 1 . Note 
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that the Examiner cited at the bottom of page 7 of the Office Action to Kojima's column 
3 f lines 4-9 and column 3 lines 10-22 but nothing in this cited text appears to disclose 
any "database index," Hence, this is another distinction of Claim 1 over Kojima. 

A sixth issue is that the Examiner has not identified what specific item in Kojima's 
disclosure is referred to as the "structure" of Claim 1 and which item is the "cache." Is 
Kojima's "data buffer areas 110" referred to as the "structure" or the "cache" (please 
note that these are two different items in Claim 1)? 

If the Examiner continues to use Kojima in a future Office Action, the Examiner is 
respectfully requested to explicitly identify what is referred to as the "structure" in 
Kojima's patent, what is referred to as the "database index" in Kojima's patent, and what 
is referred to as the "cache" in Kojima's patent. 

In explaining the rejection of Claim 1 , the Examiner further stated as follows 
towards the bottom of page 4 and top of page 5 of the current Office Action: 

In response to applicant's argument, Kojima teaches the 
result 203 of the search is shown in FIG. 2D. For example, the first 
row (E) of the salesman column of the commodity table 201 
coincides with the fourth row (E) of the employee column of the 
telephone number table 202. Therefore, the commodity X3 
belonging to the commodity column in the first row of the 
commodity table 201, and the EXT telephone number 331 
belonging to the telephone number column in the third row of the 
telephone number table 202 are listed in the first row of the result 
table 203 as shown in FIG. 2A 7 along with the coincident 
salesman's name E. The data relating to salesman B t G and C are 
similarly listed, (see e.g., col.4 lines 19-31) which is the disclosed 
limitation. 

In the above-quoted remarks the Examiner has merely shown an example of query 
processing by Kojima. Nothing in the above-quoted text appears to be related to row 
numbers of Kojima. Hence, there appears to be no disclosure in the above-quoted text, 
of storing several block-identifiers in a structure, wherein the block identifiers are of 
blocks that contain rows identified by row-identifiers in the "group." Note that Claim 1 
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now requires such storing to be performed prior to block retrieval. Hence, this is a 
seventh distinction of Claim 1 over Kojima. 

In explaining the rejection of Claim 1 , the Examiner also stated as follows 
towards the middle of page 5 of the current Office Action: 

Applicant argued Kojima does not teach the claimed 
[imitation "a single operation is performed to fetch multiple pages" 

In response to applicant's argument, Kojima teaches the 
data pages being fetched by reading out from the subsidiary 
storage into an appropriate data buffer (see, e.g. FIG. 7 and FIG. 



In the above-quoted remarks the Examiner again appears to have misunderstood 
Applicants' position. Applicants "claimed limitation" does not require fetching multiple 
pages. In particular, please note that there are no "pages" in Applicants' Claim 1. 

Furthermore, note that Kojima's FIG. 7 only shows processing of one data page. 
See Kojima's step 502 which checks if "THIS DATA PAGE IS READ OUT INTO THE 
DATA BUFFER 110?". If the answer is "NO" then step 503 is performed to "READOUT 
i-th DATA PAGE FROM THE SUBSIDIARY STORAGE INTO AN APPROPRIATE 
DATA BUFFER". Note that Kojima fetches only one data page in step 503. In Step 504 
Kojima obtains a data buffer number where the data page is stored. In step 505 Kojima 
obtains an address for the j-th slot. After step 505, the flow of Kojima's FIG. 7 simply 
ends. Hence, it appears that Kojima's fetching of a next page requires the method of 
FIG. 7 to be repeated to start from step 502 and again access subsidiary storage. 
Therefore, Kojima appears to require N accesses for N pages, i.e. one access per page. 

In contrast, a single access operation to fetch multiple blocks as per Claim 1 is 
more efficient because it avoids context switching. Claim Vs single access retrieves a 
number of blocks that are identified by a corresponding number of block-identifiers. 
This is in contrast to Kojima's use of multiple accesses, because a context-switch can 



of blocks being read if a single access is performed as per Claim 1. This makes Claim 
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occur between any two pages being accessed in Kojima's method. 

Also, a startup time for accessing subsidiary storage is spread across a number 



Page 14 of 22 



OID-2003-220-01 



PAGE 18/26 * RCVD AT 11/2312007 8:12:06 PM [Eastern Standard Time] * SVR:USPT0-EFXRM/1 « DNIS:2738300 * CSID:4083787770 * DURATION (mm-ss):08-04 



11/23/2007 18:18 FAX 408378 7 770 SVPG LLP El 019 

I 
i 

AppL No. 10/848,869 1 
Attdl dated November 29, 2QOT 

rs single access faster than Kojima's multiple individual access operations (one for 
each page). See lines 1-6 at the top of page 8 of Applicants' specification, in paragraph 
[0022]. Therefore, this is an eighth distinction of Claim 1 over Kojima. 

In explaining the rejection of Claim 1, the Examiner also stated as follows 
towards the bottom half of page 5 of the current Office Action: 

Applicant argued Kojima does not teach the claimed 
limitation "a structure containing page identifiers to fetch into a 
buffer the pages that are identified in the structure." 

In response to applicant's argument, Kojima teaches during 
the processing, data required for the processing, but not yet loaded, 
is loaded into a data buffer area 1 10 in the main storage 101 from a 
data page area 141 in a subsidiary storage (see e.g., col 3, lines 
16-19) wherein the data required for the processing disclosed the i 
limitation, 

In the above-quoted remarks the Examiner again appears to have misunderstood 
Applicants' position. Applicants "claimed limitation" does not require "page" identifiers 
and does not require fetching "pages." As noted above, that there are no "pages" in 
Applicants' Claim 1 . 

Also, note that Kojima's "data required for the processing, but not yet loaded" is 
available only after its retrieval, i.e. only after access to secondary storage. Claim 1 has 
been amended to require block identifiers to be stored in the structure prior to retrieval 
of the block. Hence, this is a ninth distinction of Claim 1 over Kojima. 

Thus, Applicants respectfully submit that Claim 1 is not anticipated by Kojima. 
Reconsideration and withdrawal of this rejection is respectfully requested. 

Claims 2-11. 13. 14 and 16-19 

Claims 2-11 depend from Claim 1 and are, therefore, likewise patentable. 
Claim 2 provides a further distinction over Kojima as follows. The Examiner cited 
to Kojima's column 1, lines 31-37 against Claim 2, which are reproduced below; 
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In a pipelined processor, data elements are fetched in 
advance of execution of an operation on the data elements by 
successively generating the addresses of the data elements to be 
fetched within a data storage, in advance of the execution of the 
operation, so that data elements are successively supplied to an 
ALU with a small time pitch. 

Nothing in the above-quoted text by Kojlma appears to disclose sorting of block 
identifiers, prior to retrieval of the blocks by performing a single access operation. The 
word "sort" is nowhere in the above-quoted text. 

New Claim 19 further distinguishes over Kojima by requiring Claim 2's sorting to 
be based on adjacency of blocks relative to one another which is not disclosed in the 
above-quoted text. For support of Claim 19, see paragraph [0030] on page 10 of 
Applicants' specification. 

I Claim 3 provides a further distinction over Kojima as follows. The Examiner cited 
to Kojima's column 1, lines 1-11 which are reproduced below: 

BACKGROUND OF THE INVENTION 

The present invention relates to a method for processing a data 
base, especially a relational data base. 

In a relational data base, data is managed conceptually in the form 
of tables. If we arrange the physical storage into the style of a table, 
however, operations such as insertion or deletion of data become 
more difficult. 

Nothing in the above-quoted text appears to support the Examiner's position that Kojima 
"explains the storage of the identifiers." The Examiner further cited to Kojima's column 
5, lines 17-21 which are reproduced below: 

In the preferred embodiment, a sort operation is done on the 
vectors 1503 and 1504 (FIG. 17) to generate the vector data 1801 
and 1802 (FIG. 18) which are obtained after arrangement of the 
vector data 1503 and 1504 in alphabetical order according to 
employee designation. 
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This text by Kojima appears to disclose sorting the data itself, which appears to be done 
after data becomes available, which in turn appears to happen after page retrieval. In 
contrast Claim 3, which depends from Claim 2, requires sorting of block identifiers, 
before retrieval of blocks. 

Claim 5 also provides a similar distinction over Kojima's column 8, lines 66-68 
and column 9 lines 1-9 at least because Claim 5 depends from Claim 1 which requires 
repeatedly finding to be performed prior to block retrieval. 

Claim 8 distinguishes over Kojima's column 7 lines 40-45 because the Examiner 
has at most shown that Kojima's buffer is the same size as the data page. The 
Examiner has not shown that the size of "data buffer area 110" has its number of buffer 
units identical to a number of page identifiers that can be held in Kojima's structure. If 
the Examiner continues to use Kojima in a future Office Action, the Examiner is 
respectfully requested to explicitly identify what is referred to as the "array" in Kojima's 
patent, what is referred to as the "number of entries" in that array, what is referred to as 
the "cache* in Kojima's patent, what is referred to as the "blocks" in that cache. 

In explaining the rejection of Claim 9, the Examiner cited to Kojima's column 7, 
lines 62-68 and column 8 lines 1-2 for explaining writing into the buffer directory. See 
the top half of page 9 of the current Office Action. Note that Claim 9 depends from 
Claim 1 and hence Claim 9's writing is required in addition to storing of blocks into the 
cac he as per Claim 1. In rejecting Claim 1, the Examiner had already used Kojima's 
writing into the buffer directory, by citing to Kojima's FIG. 7. Kojima's FIG. 7 is 
described in Kojima's column 7, lines 62-68 and column 8 lines 1-2. Hence a single 
"writing" step into Kojima's buffer directory is being used in the current Office Action to 
reject two different claim limitations in Claim 9 (including Claim 1), which is improper. 
Claim 9 is therefore patentable for this additional reason. 

I If the Examiner continues to use Kojima in a future Office Action, the Examiner is 

&^£££Z* respectfully requested to explicitly identify what is referred to as the "structure" in 
Kojima's patent, what is referred to as the "cache" in Kojima's patent and what is 
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referred to as the "log" in Kojima's patent, all of which are required by Claim 9 (via 
dependency from Claim 1). 

Note that Claim 9 is further amended now to require a write operation in 
additional to writing of logs, and this amendment is supported throughout the original 
application, including, for example, the first sentence in paragraph [0024] on page 8. 

Claim 4 was rejected over the teaching of Kojima as modified by Tolkin r s US 
Patent 6,466,942, in paragraph 8 on page 10 of the current Office Action. This rejection 
is respectfully traversed as follows. Firstly, Tolkin's column 6, lines 24-28 cited by the 
Examiner are for an updated record, and state that an update is rejected. Accordingly, 
even if the Examiner's combination is correct, the combined teachings still fail to 
disclose that duplicate checking is done in Kojima's modified method subsequent to 
finding a row in a page, but prior to storing the row number into a structure, and prior to 
retrieval of the data page itself. Instead, Kojima's modified method appears to do 
duplicate checking during update as per Tolkin. Secondly, modification of Kojima's 
method as proposed by the Examiner appears to contradict Kojima's need for fetching 
of data with regular address increment. Specifically, when processing a vector 
instruction, if a vector data element its not present due to its duplicate being present 
elsewhere, then vector data elements cannot be fetched successively as needed for 
Kojima's pipelined processing* Claim 4 is therefore patentable for these additional 
reasons. 

Claim 1 1 was rejected in the bottom half of page 1 2 of the current Office Action 
with the Examiner modifying Kojima's teachings using Vagnozzi's column 4, lines 24-32 
to explain how an offset affects storing data during processing. Vagnozzi's column 4, 
lines 24-33 is reproduced below: 

Referring to FIG. 1 , there is shown a database 20 comprising a 
table of records 22. Each of the records has a fixed length and is assigned 
a unique record number, starting with zero. This allows the records to be 
stored sequentially in a single file with the location within the file of any 
particular record simply being determined by multiplying the record length 
(in bytes) by that record's assigned record number and using the resulting 
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value as an offset from the beginning of the file. This arrangement 
provides very simple and fast allocation, de-allocation, and re-use of data 
record space within the file. 
This text by Vagnozzi appears to disclose that an offset from the beginning of a file 

determines the location of a record within the file. However, nothing in the above- 
quoted text appears to indicate that multiple file offsets are provided to a single access 
operation. Claim 1 1 is therefore patentable for this additional reason- 
Claim 10 was rejected in page 18 of the current Office Action with the Examiner 
modifying Kojima's teachings using Vagnozzi and Hashimoto (US Pub No. 
2003101 10352 A1 ). Note that US Pub No. 2003101 10352 A1 cited by the Examiner 
has a "typo" and is hereinafter presumed to be US Pub No. 20030110352 A1. 

In explaining the rejection of Claim 10, the Examiner stated that Kojima does not 
explicitly disclose unpinning each block after updating all rows etc. The Examiner then 
stated that Vagnozzi teaches a method wherein unpinning each block after updating all 
rows in said each block, in column 15, lines 23-27, which is reproduced below. 

This allows any number of other retrieval operations on the table to 
proceed concurrently, while temporarily locking out update operations. 
The database is locked at the beginning of the query processing, and 
unlocked at the end of the query processing.. 

This text by Vagnozzi appears to disclose locking and unlocking of the database. There 
appears to be no disclosure of unpinning of a block during a write operation, in the 
above-quoted text. Note that Claim 10's write operation is performed from the cache to 
the storage device when space is needed in the cache as per Claim 9 (from which 
Claim 10 depends). 

Furthermore, Claim 10's flushing of an unpinned block to disk is performed at a 
"block" level, only when another block needs space in the cache occupied by the 
unpinned block. In contrast, Hashimoto's paragraphs [0015] and [0016] cited by the 
Examiner appear to not be limited to "block" level storing of write data as shown below: 
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[0015] The write cache function performed by the hard disk drive 
controller 21 will be described next. 

[001 6] The hard disk drive controller 21 caches write data 
transferred from the upper rank system 2 In RAM 22. Upon finishing the 
receiving of the write data from the upper rank system 2, the hand disk 
drive controller 21 informs the upper rank system 2 of the finish. The hard 
disk drive controller 21 stores the write data cached in RAM 22 in the 
magnetic recording disk 31 when the cache memory is full. If a plurality of 
write data is to be stored at the same address of the magnetic recording 
disk 31 , the write data buffered earlier are abandoned and only the write 1 
data buffered latest are recorded In the magnetic recording disk 31 . If a 
plurality of write data, which makes a series of continuous data, is 
received separately using respective write commands, the write data are 
combined and stored in the magnetic recording disk 31 as one... 

Additionally, this text by Hashimoto appears to not disclose writing of a block only when 
space is needed in the cache. Claim 10 is therefore patentable for these additional 
reasons. 

Note that Applicants also hereby traverse the Examiner's modification of the 
| teachings of Kojima in view of one or more of Tolkin and/or Vagnozzi and/r Hashimoto 
for not adequately establishing a rational reason to combine these references. The 
Examiner appears to be relying on improper ex post reasoning to make the 
combination. Without the presence of Applicants' claims to act as a guide, neither one 
skilled in the art nor the Examiner would consider combining these references. 

Claims 13-18 recite one or more limitations that are supported by arguments for 
patentability that are similar one or more of the arguments presented above in reference 
to Claim 1 . Accordingly, these claims are also similarly patentable. 

Claims 15 and 20 
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Claim 15 was rejected over the teaching of Vagnozzi as the primary reference, 
wherein Vagnozzi's teachings were modified by Kojima's teachings. See paragraph 10 
on pages 16 and 17 of the current Office Action. This rejection is respectfully traversed 



OID-2003-220-01 
PAGE 24/26 * RCVD AT 11/23/2007 8:12 



Page 20 of 22 

» SVR:USPT0-EFXRF-1/1 * DNIS:2738300 ' CSlD:4083787770 * DURATION (mm-ss):08-04 



11/23/2007 18 : 20 FAX 4083787770 



SVPG LLP 



0025 



Appl No. 10/848,869 
Amdt dated Novambcr 23, 2007 

Firstly, the Examiner cited to Vagnozzi's column 10 lines 63-67, column 1 1 lines 
1-5 and column 14 lines 29-33 against the first limitation of Claim 15. However, the 
Examiner has not identified what specific item in Vagnozzi's disclosure is referred to as 
the "block", what specific item in Vagnozzi's disclosure is referred to as the "block 
identified, and what specific item in Vagnozzi's disclosure is referred to as the "pair". 

Secondly, the Examiner cited to Vagnozzi's Claim 1 for teaching storage of the 
block identifier in a structure in memory. Here as well, the Examiner has not identified 
what specific item in Vagnozzi's Claim 1 is referred to as the "structure," and what 
specific item is referred to as the "block identifier." 

Thirdly, the Examiner cited to Vagnozzi's column 12 lines 35-41 to explain 
completing the find operation multiple times. However, once again, the Examiner has 
not identified what specific step in the following text is referred to as the "find operation" 
and what specific item is referred to as the claimed "group of identifier and value pairs": 

This single result bit vector is an accumulation of all the keys 
found in the search. Each operator executes on a single Slice Type 
value and Absolute Slice Number value. Depending on the 
operator, it executes on one or more Key Data Values. These 
operators are executed multiple times to operate on more than one 
Slice Type or Absolute Slice Number. 

Is It the Examiner's position that Vagnozzi's "executes" is referred to as the find 
operation? Is it the Examiner's position that Vagnozzi's "operator* is referred to as the 
I group of identifier and value pairs? Or is it Vagnozzi's "bit vector" which is referred to as 
the group of identifier and value pairs? 

Fourthly, the Examiner admits that Vagnozzi does not disclose a vector read and 
cites to Kojima's column 6, lines 7-19 which is reproduced below. 

instruction and the displacement field (A) of the instruction, to 
indicate the detected kind of vector instruction to the vector ALU 
1709, which is comprised of a pipelined ALU. The set-up circuit 
1703 reads the vector length from a general register designated by 
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the Ri field 1609 of the instruction 1601 to send the vector length to 
the vector ALU 1709- The set-up circuit 1703 reads out an operand 
descriptor address from a general register designated by the R 2 
field 1 61 0 of the instruction 1 601 , reads out an operand descriptor 
1606 based upon the read out operand descriptor address, and. 
based upon the contents of the read out operand descriptor, reads 
out vector descriptors. The first element address and an 

Note that the above-quoted text from Kojima appears to disclose how a vector 
instruction is executed by a vector ALU. Note further that such execution appears to be 
performed by Kojima after storage of vector data with a regular address increment in 
memory (see column 1 lines 57-60). 

There appears to be no disclosure by Kojima, in the above-cited text, to retrieve 
from a disk and store in a cache, each block in a group of blocks identified by block 
identifiers in a structure, wherein the group of blocks are all stored in the cache during 
execution of a single function call. 

Thus, Applicants respectfully submit that Claim 15 is not obvious over Vangozzi's 
teachings as modified by Kojima. Reconsideration and withdrawal of this rejection is 

respectfully requested. 

New Claim 20 further distinguishes over the combination by requiring sorting 
based on adjacency of blocks relative to one another which is not disclosed in the 
combined teachings of Vangozzi and Kojima. For support of Claim 20, see paragraph 
[00301 or\ page 10 of Applicants' specification. 

For the above reasons, Applicants respectfully request allowance of all pending 
claims. Please call the undersigned at (408) 378-7777 ext 1 1 3 in case of questions. 
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